\chapter{Rich Internet Applications}
\label{chap:ria}

When it became clear that we were going to build our own LIMS we started to discuss which application model we wanted our LIMS to follow. In this chapter we will present possible application models, and any pros and cons relating to these models. 

This chapter introduces concepts and models important for this thesis. In Section~\ref{sec:applicationModels} we present and evaluate possible application models to use when developing applications. A prototype of HP LIMS was developed to evaluate whether or not developing a custom LIMS was desired. The HP LIMS prototype and our experiences from that project are briefly presented in Section~\ref{sec:prototype}, before an introduction to the concept of Rich Internet Applications is made in Section~\ref{sec:ria}, along with a number of different approaches for creating such applications. Section~\ref{sec:lookingAhead} evaluates the current state of the web development market, identifying potential potholes and arguing the pros and cons of the most promising approaches. In Sections~\ref{sec:chooseApp} and~\ref{sec:chooseTech} we will make a selection as to what approach to use when developing the application.

\section{Application models}
\label{sec:applicationModels}

There are several different models developers can follow when developing new applications. Conventionally, all applications can be separated into different levels, where each level has its own responsibilities, as described by \citeauthor{learningVaadin} \cite{learningVaadin}:

\begin{itemize}
  \item \textit{Presentation}: The presentation layer is where the user interface resides. It is responsible for displaying information and interacting with the end-user.
  \item \textit{Application logic}: The logic layer is controlling the application's functionalities and logic. The application logic is what connects the two surrounding layers.
  \item \textit{Data}: The data layer is responsible for the storage and retrieval of data, either from a file system or, in most cases, a database.
\end{itemize}

\index{Fat client model}

The \index{Client-server model|see{\\Fat client model}}client-server model is one common way of implementing a modern application. With this model, the presentation and application logic layers reside locally, while shared databases are accessed on a remote server, as can be seen in Figure~\ref{fig:fat-client}. The client-server model is also known as the fat client model \cite{learningVaadin}.

\begin{figure}[htb]
\centering
\includegraphics[scale=0.4]{figures/fat-client.eps}
\caption{The fat client model: In the fat client model, the presentation and logic layers are located on the client, while data is stored on a centralized server.}
\label{fig:fat-client}
\end{figure}

\index{Thin client model}

An alternative to the fat client model saw the light of day as system administrators realized that upgrading several hundred personal computers with the latest version of some software package could become a tedious and costly process. The thin client model and its web applications were created. With the thin client model the application logic was moved from the client to the server, see Figure~\ref{fig:thin-client}, with all the clients connecting to this central server. With the thin client model the deployment of new software can be done in a fraction of the time it would take with the fat client model, and at a fraction of the cost \cite{learningVaadin}.

\begin{figure}[htb]
\centering
\includegraphics[scale=0.4]{figures/thin-client.eps}
\caption{The thin client model: In the thin client model, only the presentation layer is on the client side, while the application logic and the date layer is located on the central server.}
\label{fig:thin-client}
\end{figure}

Although deployment of a thin client application is very cost-saving, there are, however, a few drawbacks with the thin client model as well. Firstly, as the thin client model revolves around HTML, which was not designed for the purpose of web applications in the first place, it is severely limited by the features provided by HTML. Also, there is a vast number of unrelated technologies that go into the manufacturing of web applications, making web development a more complex process than development of fat client applications \cite{learningVaadin}. The added complexity compared to development of fat client applications make thin client development cost much more, counteracting the close to no deployment cost mentioned earlier.

\section{HP LIMS prototype}
\label{sec:prototype}

As part of the evaluation process an application prototype was developed. This application was written in Java with a graphical user interface (GUI) implemented in Swing, and followed the fat client model. During the implementation process of the prototype it was argued both for and against this particular application model.

In the development of the prototype we focused on laying the foundation for a larger and more complete information system by concentrating on a few key tasks:

\begin{itemize}
	\item \textit{Extracting peptide information}: Information about peptides was to be extracted from PDF files from Thermo Fisher that accompanied each order. The prototype was created on the basis that two such PDF files accompanied each order, one depicting which peptide is located in which tube on the plates received, and the other giving a detailed description of each peptide's properties. These files were parsed to extract all the peptide information in them, including a mass spectrum image, and the peptide information extracted was stored in a database.
	\item \textit{Organizing sample information}: In addition to the information gathered from the PDF files, information about the location of each sample and each plate in the laboratory was also stored in the database.
	\item \textit{Creating a simple client with a GUI}: A simple client with a graphical user interface where users were able to import peptide data from the PDF files and store the data in the database, and subsequently search the database to view the information previously extracted from the Thermo Fisher PDF files was created. The search view from the application prototype can be seen in Figure~\ref{fig:prototype}.
\end{itemize}

\begin{figure}[htb]
\centering
\includegraphics[width=\textwidth]{figures/prototypeSearch.eps}
\caption{An application prototype was developed using the fat client model. The prototype provided amongst others a simple search interface to look up peptides in the database.}
\label{fig:prototype}
\end{figure}

Having implemented the HP LIMS prototype we concluded with the following:

\begin{itemize}
	\item \textit{Import data from PDF}: PDF is first and foremost a file format for distributing and presenting information, both on screen and on paper. It is however not suitable for extracting data programmatically, and this lead us to explore other options for importing data from file in the further development of HP LIMS.
	\item \textit{User interface improvements}: The prototype was, as mentioned above, implemented in Java using Swing to create a user interface. While Swing does provide the features needed for HP LIMS, we wanted to create an application that looked and worked like a regular desktop application, but without having to install software on every user's computer.
\end{itemize}

\section{What is a rich internet application?}
\label{sec:ria}

A Rich Internet Application (RIA) is a Web application implemented in such a way that it has many of the characteristics of typical fat client software, although it is usually accessed with a regular web browser. There exists many different approaches to how an RIA is implemented and updated, but all the different technologies do have something in common; they want to enable creation of applications which are as easy to deploy, update and maintain as the thin client, and at the same time solve the problems that come with the thin client approach.

\subsection{Different RIA approaches}
\label{subsec:riaApproaches}
The following section provides a short description of a few strategies that are considered to be under the RIA label.

\paragraph{Ajax} Ajax is not one specific technology, but rather a group of complemental techniques commonly utilized in web development to create asynchronous web applications with client-side code which can modify the DOM (Document Object Model). The DOM is a platform- and language-neutral interface that allows dynamic access to the content, structure and style of documents to programs and scripts. The document can be modified by the client-side code and it is possible to incorporate these changes back into the presented page without interfering with the pre-existing page's behaviour and display \cite{w3cDOM}. 

Ajax is an acronym for Asynchronous JavaScript and XML, and was amongst the first successful RIA solutions \cite{learningVaadin}. With this approach, web applications can interact with a server asynchronously (in the background) without interfering with the application's behaviour. When receiving a response from the server to a request made by the client, the script handling the request is correspondingly able to manipulate the DOM in accordance with the data in the response, and update parts of the DOM.

\paragraph{Plugins for richness} Executing code on the client side through the web browser's plugin interface was the first approach to RIAs. Sun came up with applets, while Microsoft proposed ActiveX. Neither of the two technologies were a success, they both experienced major performance and security issues \cite{learningVaadin}. Other alternatives using the plugin approach include the Microsoft Silverlight and Adobe Flex technologies. Adobe's Flex is based on the Adobe Flash platform.

\paragraph{Fat clients from the web} A third and more direct approach to RIAs is to create a regular fat-client application, and deploy this over the web. One technology utilizing this approach is Java Web Start (JWS). We will not go into detail about JWS, but although JWS does handle all the problems connected to the thin client approach very well according to \citeauthor{learningVaadin} \cite{learningVaadin}, it had some problems of its own which ultimately lead to JWS not becoming the technology it had the potential of becoming. Extended startup times due to the fact that large amounts of data have to be transmitted over the Internet before one is able to use the application is considered a major drawback with JWS.

\paragraph{Google Web Toolkit} Google is providing a development toolkit designed to build browser-based applications called Google Web Toolkit (GWT). GWT enables developers without extensive knowledge to JavaScript, the DOM and web-browsers to write Ajax applications in pure Java. GWT compiles the Java sources to JavaScript \cite{gwt}. GWT is used extensively to create Ajax applications, but for simplicity we will treat GWT and Ajax as separate terms in this thesis.

Although GWT provides a high degree of abstraction on top of common web development approaches, some of the dirty details are still out in the open, and the DOM is not completely abstracted away \cite{learningVaadin}. Also, with GWT the developer has to write the code to handle the client-server communication \cite{gwtServer}, meaning that although many of the concepts related to web development has been abstracted away there is still a requirement of thorough knowledge to related technologies such as remote procedure calls (RPC) or HTTP requests.

\paragraph{HTML5}

HTML5 is still a work in progress and currently only has status as a working draft \cite{html5Diff}, but some of the major web browsers have already implemented support for some of the features present in HTML5. While standardizing several important web development ideas which have been introduced after the release of the HTML 4.01 specification in 1999, see \cite{html4Spec}, \citeauthor{Pilgrim:2010} \cite{Pilgrim:2010} states that HTML5 also provides new features that allow for implementation of modern web applications. HTML5 introduces several new APIs, which used together with the new elements introduced in HTML5 provides a lot of features that are very helpful in the development of web applications \cite{html5Diff}. 

\section{Looking ahead - potential bumps in the road}
\label{sec:lookingAhead}

Although there clearly exists many cons regarding the thin client approach of developing software, a significant amount of applications in development today utilize this approach, most of which use an Ajax driven approach. We have still to see a clear market leader in regard to web application development.

\subsection{State of the market}

While the Adobe Flex technology seemed to be a good candidate it had a rugged start, as Apple did not include Flash support with their portable devices running iOS (the iPhone and iPad). This deemed Flash-based technologies disadvantagous for developing web applications as the application would not be available for users trying to gain access from these devices. This is, however, no longer an issue as iOS now supports Flex \cite{adobeFlex}. However, there is a new issue at hand as Adobe has announced that it will no longer develop its Flash player for mobile devices. Adobe is now focusing on HTML5 for mobile devices, while continuing the development of the Flash player for PC browsing \cite{adobeFlashVsHtml}.

While, as mentioned earlier, HTML5 is still only a working draft many of the big players on the web, such as Google, Apple and Microsoft, have started adopting to the new features provided by HTML5. Support for parts of HTML5 has come to their respective web browsers (Chrome, Safari and Internet Explorer), and more of the HTML5 features is continually added to the web browsers as work on HTML5 is progressing.

GWT is still an interesting alternative, but it is a complex solution to utilize in implementation, requiring a lot of background knowledge to fully exploit its potential.

\subsection{What to choose?}

So, is there an obvious choice to which technology is best for creating RIAs? Probably not. It is important to make an informed decision when selecting which technology/technologies to use. Selecting something that will be maintained for a long time and that provides the necessary functionality based on the type of users and devices accessing the application is critical.

If one selects Flex, it is important to take into account that Flash for mobile devices seems to be dying - if the application is not at all intended for mobile users Flex could still be a good alternative.

There seems to be a widespread conception in certain circles that HTML5 is the future of RIAs, and it does indeed look very promising. It is however important to take into account that there still isn't widespread support for HTML5 across all web browsers and that development of this technology is still ongoing.

\section{Choosing an application model}
\label{sec:chooseApp}

After careful consideration weighing the pros and cons of the fat and thin client application models it was decided that HP LIMS was to be developed with the thin client approach. The main reason the choice was made to implement the application with the thin client approach was that we wanted the developer to be in control of the software. With the thin client approach, we are always ensured that the users are using the latest version of the software as soon as it is available.

\section{Choosing a technology}
\label{sec:chooseTech}

We carefully evaluated the different technologies outlined in Chapter~\ref{subsec:riaApproaches} to figure out which technology we wanted to use.

Adobe Flex and the other plug-in based alternatives were not what we were looking for as we did not wish to be dependent on third party browser plug-ins such as Adobe Flash or Microsoft Silverlight. Deploying a fat client from the web with, e.g., JWS was not considered an option due to the many drawbacks with this technology, amongst others the need to transfer huge amounts of data over the Internet even before being able to run the application.

We were left with three common alternatives: GWT, Ajax and HTML5. Although HTML5 seemed, and still seems, very promising in regard to developing RIAs, we considered HTML5 to be too immature at the time, and we were left with the option to create a GWT application or to create an Ajax application. Both alternatives require a high degree of knowledge of several different technologies incorporated into these two approaches. For this reason we started looking for potential frameworks to utilize in the development of HP LIMS.

\subsection{Evaluating Java web frameworks}
\label{sec:evaluatingJavaFrameworks}

As we wanted to develop the backend of the application in Java (see Chapter~\ref{sec:Java} about the Java programming language), we started looking for server-side frameworks enabling fast and easy web development in Java. There are many alternatives out there, including but not limited to, Grails, Struts 2, Vaadin, Play and Spring. We decided to further evaluate two of these by making a prototype utilizing each framework.

\paragraph{Play! Framework} Play is a relatively new framework, having been in development since 2007 and open sourced in 2009. It is based on a lightweight and stateless architecture, and integrates fully with existing Java code while also providing native support for Scala development. With Play the backend of the application is written in either Java or Scala, or both, while the frontend is written in HTML combined with JavaScript. JavaScript is what binds the front- and backends together, enabling asynchronous programming \cite{playIntro}.

\paragraph{Vaadin} Vaadin is a free, open source framework which has been developed by Vaadin, formerly IT Mill, for over a decade \cite{learningVaadin}, something which means that Vaadin is a technology that will persist for many years to come. Vaadin combines the use of the GWT and Ajax technologies to create an RIA as an object-oriented Java application, and provides the developer with many advantages compared to a pure GWT or Ajax approach. The developer implements a Java application where Vaadin provides a large collection of UI components. Vaadin combines GWT and Ajax on the client-side to ensure a rich and interactive user experience, while abstracting away all the quirks associated with each of these approaches, and its robust server-side architecture ensures that the majority of the logic runs on the server-side and not the client-side \cite{whatIsVaadin}.

\subsubsection{Framework requirements}

To evaluate the frameworks we looked at the following criteria during the development of the prototype: 

\begin{itemize}
  \item \textit{Developer productivity}: How long did it take to develop the prototype in each framework?
  \item \textit{Learning curve}: Is it easy to learn how to develop applications with this framework? 
  \item \textit{Ajax support}: How is Ajax handled?
  \item \textit{Availability of plugins or add-ons}: Are there plugins that might ease development of some features?
  \item \textit{Documentation/tutorials}: Is the framework well documented?
  \item \textit{Community}: Are others using this framework?
  \item \textit{Degree of risk}: Will the development of the framework cease at some point?
\end{itemize}

\subsection{Comparing frameworks}
\label{sec:comparingFrameworks}

Both Play and Vaadin have tools that helps the developer get started with development. Play comes with a command line tool which generates a project for you, while Vaadin enables integration with major IDEs such as Eclipse and Netbeans through a plug-in (read more about the Eclipse IDE in Chapter~\ref{sec:eclipse} on page~\pageref{sec:eclipse}). Play's command line tool is also able to generate IDE-specific projects automatically. As such, it is fairly easy to get started with an implementation in both frameworks.

Both frameworks come across as simple to get started with, but the learning curves, depending on developer experience, will soon become fairly different. Whereas Play's views are written in HTML and Ajax support is handled by utilizing JavaScript, Vaadin has an entirely different approach. As previously mentioned, Vaadin comes with a number of UI components. Views in Vaadin are written purely in Java by utilizing these components, in an object-oriented fashion, and Ajax is handled by Vaadin. Thus, Ajax is, in essence, enabled by default, without any major effort from the developer. The Vaadin API is simple and easy to understand, and with views written in pure Java, the developer has no need to learn HTML or JavaScript in order to create a fully functional view. With the Play framework the developer has to embed custom JavaScript in the HTML views to get a view with Ajax functionality. Without any prior knowledge to JavaScript or HTML, the learning curve for the Play framework is much steeper than the learning curve for Vaadin, which only requires knowledge about one programming language.

An important point when one is inexperienced with a framework is the possibility to get help when running into a problem. As such, it is important that the framework is well documented, and if the problem is not at all general, getting help from others using the same framework can be crucial. Both Play and Vaadin are very well documented, there are comprehensive tutorials for getting started with development in both frameworks, and several books have been released about application development in each of them. Vaadin offers one free book about the framework, the Book of Vaadin, which is available online in HTML or PDF format, in addition to the printed version. The Vaadin community portal is used by more than 80,000 developers each month \cite{vaadinDock}, and the Vaadin add-on directory\footnote{https://vaadin.com/directory} contains more than 200 add-ons, both official releases from the Vaadin team and community developed add-ons. There is an unspecified number of add-ons (modules) for Play available in the module repository\footnote{http://www.playframework.org/modules}.

The degree of risk associated with each of these frameworks seems to be quite low. Both Play and Vaadin have backing by a company: Vaadin is developed by Vaadin Ltd., based in Finland; while Play is developed at Zenexity, out of France.

\subsection{Selecting a framework}

Having compared Vaadin and Play it became clear that while the frameworks are both very easy to set up and get started with development, there are some crucial differences in regard to how the application development process works. An important point is the way Ajax support is handled and how the views are built. It quickly became clear that the developer productivity (for a developer inexperienced with JavaScript) was much higher when developing an application with Vaadin, compared to Play. The Play learning curve was much steeper than that of Vaadin, and while both frameworks have a great community to turn to for support when issues come up, Vaadin emerged as the better alternative for development of HP LIMS. More about Vaadin can be found in Chapter~\ref{sec:vaadin}.

\section{Summary}
\label{sec:riaSummary}

In this chapter we have evaluated the fat and thin client models as possible application models to utilize when implementing the application. Both of these models have their advantages and disadvantages: the fat client is easy to develop, but can be expensive and cumbersome to maintain as the number of users rises; the thin client model is easy and inexpensive to maintain, but in general it comes with a higher cost of development than the fat client model due to the added complexity of the software. 

We have also introduced the concept of Rich Internet Applications. RIAs are web applications implemented in such a way that they have many of the characteristics of the fat client model, but are in reality based on the thin client approach. Strategies that fall under the RIA label are Ajax, which uses asynchronous programming to enable communication between the client and the server in the background; plug-in based applications, which are based on, e.g., the Microsoft Silverlight or Adobe Flash platforms; fat clients deployed from the web, such as JWS applications; GWT, Google's Java framework which compiles Java code to browser-independent JavaScript code; and HTML5, currently a working draft, which standardizes many ideas from the last 10 years of web development and introduces several new APIs which are useful when developing web applications.

We have assessed the current state of the web development market, looking for the most optimal solutions with regard to future development and the future of the currently available technologies. Two different Java web frameworks have been evaluated, the Vaadin and Play frameworks. Each framework utilizes different RIA strategies to create web applications. Both frameworks base the communication between the server and the client on Ajax. Vaadin, which comes with built-in Ajax integration and utilizes GWT as the client side engine, emerged as the better alternative of the two after having implemented a prototype with each framework.